home *** CD-ROM | disk | FTP | other *** search
-
- On Wednesday, February 26th, the NEARnet Steering Committee accepted the
- recommendation of the technical subcommittee by adopting the following policy
- for the routing of CLNS traffic within NEARnet. It is hoped that this plan
- will assist OSI interoperability testing between developers and lead to more
- mature OSI products in the future.
-
- Please direct any questions or comments to "nearnet-eng@nic.near.net".
-
- John Curran
- NEARnet Staff
- ---
-
- NEARnet OSI Routing Plan
-
-
- This is an informational document specifying guidelines for the implementation
- of Open Systems Interconnection (OSI) connectionless network protocol (CLNP)
- networking within NEARnet. The document describes a plan for coordinating OSI
- addressing, assigning routing domains to NEARnet members, establishing CLNP
- routing within NEARnet, and coordinating CLNP routing with external networks.
- This document does not specify that NEARnet will offer CLNS transport service;
- requests for CLNS non-production trials will be accepted from members with
- existing expertise (as demonstrated by a history of the support of CLNS on
- their own internal networks.)
-
- This document is intended for NEARnet members but may be useful to other
- members of the Internet community. Much of the material herein is based upon
- the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda
- Winkler (ANL) and NEARnet is grateful for their assistance. It is hoped that
- documents such as these will help encourage the growth of OSI services within
- the Internet.
-
-
- NEARnet OSI Addressing
- ======================
-
- In OSI, each system is associated with a Network Service Access Point (NSAP)
- address. NSAP's are analogous to Internet Protocol (IP) addresses in that each
- system must be assigned a unique address in order to successfully communicate.
- In IP, the addresses that a given system may be assigned is constrained by the
- IP network number it is attached to. This allows for abstraction of routing
- information by other networks. NSAP's are structured in a similar manner which
- allows abstraction of routing information to occur at many different levels in
- the network.
-
- The document that defines the semantics of an NSAP is ISO 8348/Addendum 2.
- The basic components of the NSAP is the initial domain part (IDP) and the
- domain specific part (DSP). The initial domain part identifies the authority
- that is responsible for both the structure and the uniqueness of the address.
- In NEARnet, the vast majority of the NSAP's encountered will be within the same
- initial domain part: 47.0005. This is the portion of the NSAP address space
- which is assigned to the U.S. Government. This IDP is administered by the
- General Services Administration (GSA) for the National Institute of Standards
- and Technology (NIST). U.S. organizations may apply to GSA for their own unique
- prefix for the domain specific portion of this address space, and such prefixes
- are known as administrative authority identifiers.
-
- NEARnet has been assigned an Administrative Authority (AA) value by the GSA.
- This AA value identifies a set of NSAP addresses which may be allocated to
- NEARnet members as needed. The AA assigned to NEARnet is FFFE00 (16) and the
- addresses follow the GOSIP V2 NSAP format:
-
- 47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL
-
- where rsvd is two reserved octets of zero
- RD is a two octet routing domain
- Area is a two octet area within the RD
- ID is a six octet system identifier
- and SEL is a one octet nsap selector.
-
- The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out
- of the NEARnet AA. Each NEARnet member will be assigned one or more RDs from
- the NEARnet AA. Each member will have the authority to assign Area Identifiers
- (2 bytes) within its RD to best serve its topology and its users. NEARnet
- backbone routers will carry only information about members' routing domains,
- and will not carry information about member area assignments. As a result,
- each member's local addressing and topology will be transparent to the NEARnet
- backbone routers. Sites with connections to networks in different AAs, or
- whose primary path is a network other than NEARnet may want to obtain an RD
- >From that network's administrative authority.
-
- For NEARnet members who are assigned an AA by another authority, the NEARnet
- backbone routers will carry the minimum amount of information needed to route
- to that member. In some cases it may be necessary for members to acquire their
- own Administrative Authority assignment if they desire multiple network
- connections to provide automatic failover between providers.
-
-
- NEARnet CLNP Routing
- ====================
-
- Any NEARnet member which participates in CLNS transport will provide an NSAP
- address for the NEARnet router on their network. The NEARnet router will use
- Cisco's IGRP to exchange CLNP routing information with a site if the site is
- using a Cisco router. If it is not, static CLNP routing will be used until
- the ISO Interdomain Routing Protocol (IDRP) is widely available from router
- vendors.
-
- Routing between AAs will occur where NEARnet peers with other network service
- providers. Such routing exchanges will involve the minimum information needed
- to represent the networks served. In the initial case, NEARnet will provide
- other network providers with a route to NEARnet's AA prefix which will be
- sufficient to route to all NEARnet provided routing domains. Additional routes
- would be exchanged as NEARnet members acquire their own AA assignments. Again,
- IGRP or static routing will be used to facilitate these routing exchanges
- until IDRP is readily available.
-
- Routing within NEARnet will use IGRP. Each NEARnet router will be assigned
- as NSAP from a single NEARnet backbone routing domain. Member routing domains
- will be assigned based upon the hub or branch node connected into, which will
- allow for route aggregation at each hub. This aggregation will reduce the
- routing workload on the individual routers, and will also allow for future
- network topologies based upon state or LATA boundaries. It is expected that
- members may move from branch node to branch node in the future; the goal of
- allocating routing domains is simply an optimization which allows for route
- compression for the normal case.
-
- NEARnet Routing Domain Requests
- ===============================
-
- Members who require a routing domain assignment for participation in
- OSI networking should fill out a Routing Domain Assignment request
- (available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt)
- and mail the completed request to "nearnet-eng@nic.near.net".
-
-
- From jcurran@nic.near.net Fri Feb 28 14:23:14 1992
- Received: from nic.near.net by merit.edu (5.65/1123-1.0)
- id AA21419; Fri, 28 Feb 92 14:14:23 -0500
- Message-Id: <9202281914.AA21419@merit.edu>
- To: osi-interop@merit.edu
- Subject: NEARnet OSI Routing Plan
- Date: Fri, 28 Feb 92 14:14:21 -0500
- From: John Curran <jcurran@nic.near.net>
- Status: RO
-
- FYI.
- /John
-
- ------- Forwarded Message
-
- Received: from nic.near.net by nic.near.net id aa18311; 28 Feb 92 13:12 EST
- To: nearnet-tech@nic.near.net
- cc: nearnet-tc@nic.near.net
- Reply-to: nearnet-eng@nic.near.net
- Subject: NEARnet OSI Routing Plan
- Date: Fri, 28 Feb 92 14:11:26 -0500
- From: John Curran <jcurran@nic.near.net>
-
- On Wednesday, February 26th, the NEARnet Steering Committee accepted the
- recommendation of the technical subcommittee by adopting the following policy
- for the routing of CLNS traffic within NEARnet. It is hoped that this plan
- will assist OSI interoperability testing between developers and lead to more
- mature OSI products in the future.
-
- Please direct any questions or comments to "nearnet-eng@nic.near.net".
-
- John Curran
- NEARnet Staff
- - ---
-
- NEARnet OSI Routing Plan
-
-
- This is an informational document specifying guidelines for the implementation
- of Open Systems Interconnection (OSI) connectionless network protocol (CLNP)
- networking within NEARnet. The document describes a plan for coordinating OSI
- addressing, assigning routing domains to NEARnet members, establishing CLNP
- routing within NEARnet, and coordinating CLNP routing with external networks.
- This document does not specify that NEARnet will offer CLNS transport service;
- requests for CLNS non-production trials will be accepted from members with
- existing expertise (as demonstrated by a history of the support of CLNS on
- their own internal networks.)
-
- This document is intended for NEARnet members but may be useful to other
- members of the Internet community. Much of the material herein is based upon
- the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda
- Winkler (ANL) and NEARnet is grateful for their assistance. It is hoped that
- documents such as these will help encourage the growth of OSI services within
- the Internet.
-
-
- NEARnet OSI Addressing
- ======================
-
- In OSI, each system is associated with a Network Service Access Point (NSAP)
- address. NSAP's are analogous to Internet Protocol (IP) addresses in that each
- system must be assigned a unique address in order to successfully communicate.
- In IP, the addresses that a given system may be assigned is constrained by the
- IP network number it is attached to. This allows for abstraction of routing
- information by other networks. NSAP's are structured in a similar manner which
- allows abstraction of routing information to occur at many different levels in
- the network.
-
- The document that defines the semantics of an NSAP is ISO 8348/Addendum 2.
- The basic components of the NSAP is the initial domain part (IDP) and the
- domain specific part (DSP). The initial domain part identifies the authority
- that is responsible for both the structure and the uniqueness of the address.
- In NEARnet, the vast majority of the NSAP's encountered will be within the same
- initial domain part: 47.0005. This is the portion of the NSAP address space
- which is assigned to the U.S. Government. This IDP is administered by the
- General Services Administration (GSA) for the National Institute of Standards
- and Technology (NIST). U.S. organizations may apply to GSA for their own unique
- prefix for the domain specific portion of this address space, and such prefixes
- are known as administrative authority identifiers.
-
- NEARnet has been assigned an Administrative Authority (AA) value by the GSA.
- This AA value identifies a set of NSAP addresses which may be allocated to
- NEARnet members as needed. The AA assigned to NEARnet is FFFE00 (16) and the
- addresses follow the GOSIP V2 NSAP format:
-
- 47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL
-
- where rsvd is two reserved octets of zero
- RD is a two octet routing domain
- Area is a two octet area within the RD
- ID is a six octet system identifier
- and SEL is a one octet nsap selector.
-
- The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out
- of the NEARnet AA. Each NEARnet member will be assigned one or more RDs from
- the NEARnet AA. Each member will have the authority to assign Area Identifiers
- (2 bytes) within its RD to best serve its topology and its users. NEARnet
- backbone routers will carry only information about members' routing domains,
- and will not carry information about member area assignments. As a result,
- each member's local addressing and topology will be transparent to the NEARnet
- backbone routers. Sites with connections to networks in different AAs, or
- whose primary path is a network other than NEARnet may want to obtain an RD
- from that network's administrative authority.
-
- For NEARnet members who are assigned an AA by another authority, the NEARnet
- backbone routers will carry the minimum amount of information needed to route
- to that member. In some cases it may be necessary for members to acquire their
- own Administrative Authority assignment if they desire multiple network
- connections to provide automatic failover between providers.
-
-
- NEARnet CLNP Routing
- ====================
-
- Any NEARnet member which participates in CLNS transport will provide an NSAP
- address for the NEARnet router on their network. The NEARnet router will use
- Cisco's IGRP to exchange CLNP routing information with a site if the site is
- using a Cisco router. If it is not, static CLNP routing will be used until
- the ISO Interdomain Routing Protocol (IDRP) is widely available from router
- vendors.
-
- Routing between AAs will occur where NEARnet peers with other network service
- providers. Such routing exchanges will involve the minimum information needed
- to represent the networks served. In the initial case, NEARnet will provide
- other network providers with a route to NEARnet's AA prefix which will be
- sufficient to route to all NEARnet provided routing domains. Additional routes
- would be exchanged as NEARnet members acquire their own AA assignments. Again,
- IGRP or static routing will be used to facilitate these routing exchanges
- until IDRP is readily available.
-
- Routing within NEARnet will use IGRP. Each NEARnet router will be assigned
- as NSAP from a single NEARnet backbone routing domain. Member routing domains
- will be assigned based upon the hub or branch node connected into, which will
- allow for route aggregation at each hub. This aggregation will reduce the
- routing workload on the individual routers, and will also allow for future
- network topologies based upon state or LATA boundaries. It is expected that
- members may move from branch node to branch node in the future; the goal of
- allocating routing domains is simply an optimization which allows for route
- compression for the normal case.
-
- NEARnet Routing Domain Requests
- ===============================
-
- Members who require a routing domain assignment for participation in
- OSI networking should fill out a Routing Domain Assignment request
- (available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt)
- and mail the completed request to "nearnet-eng@nic.near.net".
-
- ------- End of Forwarded Message
-
-
-